home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1056 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.1 KB
  1. From: clamage@Eng.Sun.COM (Steve Clamage)
  2. Message-ID: <4klsr0$ii4@engnews1.Eng.Sun.COM>
  3. X-Original-Date: 12 Apr 1996 15:28:32 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 12 Apr 96 16:25:37 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Draft Std. C++ Preprocessor
  9. Organization: Sun Microsystems Inc.
  10. References: <mike_duigou-0804961108400001@news.aimnet.com>
  11. Reply-To: clamage@Eng.Sun.COM
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMW6EEOEDnX0m9pzZAQHJggF/Qnb0IthCPYg5CsJPzUn5+Qz6dnwgo1kI
  14.     EqQcqjyMre5nUM1m4zaPvXyEse/0ynTS
  15.     =OELN
  16.  
  17. In article 0804961108400001@news.aimnet.com, mike_duigou@fwb.com (Mike Duigou)
  18. writes:
  19. >While reading parts of the April 1995 draft I noticed that the section on
  20. >preprocessing seemed to be pretty much the same as the ANSI C
  21. >preprocessor. Was there a concious descision to make no changes?
  22.  
  23. Yes. The intent is to make preprocessing behave exactly the same way,
  24. except of course for the predefined macros __STDC__ and __cplusplus.
  25.  
  26. It is hoped that eventually the preprocessor can be eliminated. The
  27. presence of the preprocessor makes code analysis very difficult for
  28. programs and for humans. Macros are dangerous for numerous reasons.
  29. Conditional compilation in practice turns out to make code less
  30. understandable and less maintainable than other techniques that do not
  31. depend on preprocessing. In principle, an "include" directive could
  32. be added to the language proper, eliminating the need for #include.
  33. Few indeed are the preprocessor functions that cannot be achieved
  34. equally well in the C++ language proper already. (Realistically, we
  35. probably cannot eliminate the preprocessor. But we don't have to
  36. encourage its use.)
  37.  
  38. >One change I was hoping for was the inclusion
  39. >of a non-fatal "#warning" directive to match the fatal '#error" directive.
  40. >(hey, the compiler can make both errors and warnings, why can't I?). As
  41. >you probably know, a number of compilers support the #warning directive.
  42.  
  43. We've been through this discussion many times. The #error directive isn't
  44. required to be fatal. All that is required is that it cause a message to
  45. be emitted. It is difficult to specify "fatal" versus "non-fatal" in a
  46. system-independent way. For example, I assume you mean that an #error
  47. directive should prevent the program from being linked or run, since the
  48. failure would occur at compile time. But what about a pure interpreter?
  49. The program could be already executing when the #error directive was
  50. encountered. We don't like to require things in the standard that
  51. make it impossible to have conforming implementations that would be
  52. otherwise useful.
  53.  
  54. Adding non-standard directives like #warning is not very programmer-
  55. friendly. The #pragma mechanism exists precisely as a hook to add
  56. special behavior without causing compile failures on systems that
  57. don't have the facility. Implementors who want to add a programmer
  58. warning facility would be better advised to make it "#pragma warning".
  59.  
  60. >Additionally, adding some reccomended pragmas such as ...
  61.  
  62. There is no end to things that might be nice. "Recommending" something
  63. in the standard has no real meaning. Either that something is required,
  64. in which case you can depend on it being available, or it is not
  65. required, in which case you cannot depend on it being available.
  66.  
  67. Pragmas, in my view, are best used for things which do not affect
  68. program semantics. "Pragma warning" is an example of such a pragma.
  69. "Pragma once" is an example of a pragma which does affect the meaning
  70. of a program, and can cause compile failures when the code is moved to
  71. a system that doesn't support it. Worse still (IMHO) are pragmas that
  72. change meaning without affecting legality. Your code then inexplicably
  73. behaves differently on different systems.
  74. ---
  75. Steve Clamage, stephen.clamage@eng.sun.com
  76. ---
  77. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  78. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  79. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  80. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  81. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  82.